Conceptually, public keys behave a lot like telephone numbers—if I want to call you, I need your telephone number. I don't need my own number to make calls (I can use a pay phone, for example); I need a number to receive calls. In a fashion that is analogous to a telephone number, I need your public key to encrypt something so that it is secret to you.
Unlike telephone numbers, public keys are far too big for people to remember. Even elliptic curve keys, which are much shorter than the traditional ones are far too large for a person to remember. A 160-bit key is over 40 digits long (exactly 40 if one uses hexadecimal). So memorizing someone's key the way one memorizes a phone number is completely out of the question.
Consequently, we need to have blobs of data that say that a name such as alice@example.com belongs to some key. There is also value in digitally signing the data so that the receiver has some assurance that the association is accurate. These blobs are certificates.
Like any data management problem, certificate management is harder than people would like. This is why in 1984 Adi Shamir suggested the idea of coming up with a crypto scheme in which any string can be a public key See, A. Shamir, Identity-based Cryptosystems and Signature Schemes, Proceedings of CRYPTO '84, LNCS 196, pages 47-53, Springer-Verlag, 1984. Thus, there is no need to associate a name with a public key, because they're effectively the same. This is Identity-Based Encryption (IBE).
While we typically think of IBE systems converting names into public keys, it should be possible to make any arbitrary bit-string, ID ε {0,1}*, a determinant of a public key in an IBE system. Thus, a name, an email address, or even a binary object such as a picture or sound can be considered equivalent to a public key. Thus, an IBE system can be thought of as a function of the form Ki=IBE(IDi) that produces keys from arbitrary bit strings that we call identities, without loss of generality.
An IBE system contains four basic components in its construction:                1. System Setup: IBE systems rely upon a trusted central authority that manages the parameters with which keys are created. This authority is called the Private Key Generator or PKG. The PKG creates its parameters, including a master secret Kpkg from which private keys are created.        2. Encryption: When Bob wishes to encrypt a message to Alice, he encrypts the message to her by computing or obtaining the public key, PAlice, and then encrypting a plaintext message M with PAlice to obtain ciphertext C.        3. Key Extraction: When Alice wishes to decrypt the message C that was encrypted to her name, she authenticates herself to the PKG and obtains the secret key SAlice that she uses to decrypt messages.        4. Decryption: When Alice has C and SAlice, she decrypts C to obtain the plaintext message M.No matter the specific parameters or requirements of the system, these functional aspects are always present in IBE systems as their defining components.        
All of the existing IBE systems have their own limitations. One system signs but does not encrypt. Another system needs care to avoid an adaptive chosen ciphertext attack. While other systems have proofs of security, there is a notoriously poor relationship between proofs of security and actual system security. Security proofs can show where a system is safe, but not protect against new assumptions that an adversary can bring to bear against the system nor against uses of a system that its creators did not think of which may be outside of the scope of the original threat model. Still other subtle problems have shown up on other systems, such as the ability for colluding users to determine the PKG's master key.
With the exception of Shamir's system, IBE systems rely on new public-key cryptosystems, most often Weil pairing. Consequently, they are not compatible with existing systems that use RSA (the Rivest-Shamir-Adleman algorithm), Elgamal, or DSA (Digital Signature Algorithm). This limits their practical application, since there are many existing systems built upon these cryptosystems. Also, experience and comfort with the security of these established systems is high. A key advantage that Shamir's system has over all those that follow it is that it was based on established public key cryptography, and thus (had it been successful in being both a signing and encrypting system) is interoperable with non-IBE systems. Had Shamir s system been successful at encrypting, an RSA-based IBE system would likely be the dominant IBE system today, if for no other reason than its interoperability with deployed systems. This is an important observation—if one can construct an IBE system that uses traditional, integer-based, public key cryptography, the barriers to adoption of IBE systems might be lowered. The value that IBE has can be fully realized if it can be made to work with these established systems. Working with established systems has the advantage of relying on twenty years of mathematical and operational familiarity associated with these traditional public-key cryptosystems.
Previous IBE systems have as a desirable property that they support off-line generation of keys. That is to say, one receives key-generation parameters from the PKG once, and can then generate an arbitrary number of public keys. Off-line generation is ideal in an off-line environment. If communication with the PKG is slow, expensive, or unreliable, then off-line generation is a huge advantage to its users. They need only one interaction with a given PKG to be able to do all needed work with that server.
This advantage becomes less significant as communication with a PKG becomes cheaper, easier, and faster. On some level, off-line key generation is nothing more than a key server that is an algorithm instead of a database. This is an advantage when databases are static and expensive, but not when databases are cheap and fast. In an environment where the contents of the database are dynamically changing, a database change is not only an algorithm change, but an algorithm change that must be propagated to all clients of the PKG.
Oftentimes, the strengths of a system are also its weaknesses. This is also true with off-line generation. Off-line generation makes key generation easy not only for legitimate users of the system but for illegitimate ones as well. An issue that PKIs must consider in their design is that of a Directory Harvest Attack, in which senders of unwanted advertisements or outright fraudulent confidence games use the directory as a way to discover information paths into the system. Off-line generation of keys allows spammers and other attackers to pre-generate email attacks in their own system or create a distributed system for encrypted attacks. These attacks are not an issue in off-line systems. Off-line generation has the disadvantage that there is complete transparency in the directory, since the directory is an algorithm. Anyone with that algorithm has all possible entries in the directory and their public keys, and this can be exploited in side-channel attacks that are not attacks on the cryptographic system per se, but the way the system is used.
Off-line generation has as an additional disadvantage of increased revocation problems. A conventional PKI must be able to re-issue certificates and handle revisions in the PKI. An off-line IBE system must not only handle revocation of the certificates themselves but a revocation of the algorithmic parameters that comprise its own PKI. No IBE system has even considered this real-world problem.
In view of the foregoing, it would be desirable to develop an improved IBE system that overcomes the shortcomings associated with prior art IBE systems.